Bortom exempel: En djupdykning i egenskapbaserad testning i JavaScript

Som mjukvaruutvecklare spenderar vi en betydande mängd tid på att skriva tester. Vi utformar noggrant enhetstester, integrationstester och end-to-end-tester för att säkerställa att våra applikationer är robusta, pålitliga och fria från regressioner. Det dominerande paradigmet för detta är exempelbaserad testning. Vi tänker på en specifik indata och vi påstår en specifik utdata. Indata `[1, 2, 3]` ska producera utdata `6`. Indata `"hello"` ska bli `"HELLO"`. Men detta tillvägagångssätt har en tyst, lurande svaghet: vår egen fantasi.

Tänk om du glömmer att testa med en tom array? Ett negativt tal? En sträng som innehåller Unicode-tecken? Ett djupt kapslat objekt? Varje missat gränsfall är en potentiell bugg som väntar på att hända. Det är här egenskapbaserad testning (PBT) kommer in i bilden och erbjuder ett kraftfullt paradigmskifte som hjälper oss att bygga säkrare och mer motståndskraftig mjukvara.

Denna omfattande guide kommer att guida dig genom världen av egenskapbaserad testning i JavaScript. Vi kommer att utforska vad det är, varför det är så effektivt och hur du kan implementera det i dina projekt idag med det populära biblioteket `fast-check`.

Begränsningarna med traditionell exempelbaserad testning

Låt oss överväga en enkel funktion som sorterar en array med tal. Med ett populärt ramverk som Jest eller Vitest kan vårt test se ut så här:

            // En enkel (och något naiv) sorteringsfunktion
function sortNumbers(arr) {
  return [...arr].sort((a, b) => a - b);
}

// Ett typiskt exempelbaserat test
test('sortNumbers bör sortera en enkel array korrekt', () => {
  const inputArray = [3, 1, 4, 1, 5, 9];
  const expectedArray = [1, 1, 3, 4, 5, 9];
  expect(sortNumbers(inputArray)).toEqual(expectedArray);
});
            

              
                Copy
              
            
          

Detta test passerar. Vi kan lägga till några fler `it`- eller `test`-block:

• En array som redan är sorterad.
• En array med negativa tal.
• En array med noll.
• En tom array.
• En array med dubbletter (vilket vi redan täckt).

Vi känner oss bra. Vi har täckt grunderna. Men vad har vi missat? Vad sägs om `[-0, 0]`? Vad sägs om `[Infinity, -Infinity]`? Vad sägs om en mycket stor array som kan träffa prestandagränser eller konstiga JavaScript-motoroptimeringar? Det grundläggande problemet är att vi manuellt väljer data. Våra tester är bara så bra som de exempel vi kan tänka oss, och människor är notoriskt dåliga på att föreställa sig alla konstiga och underbara sätt som data kan struktureras.

Exempelbaserad testning validerar att din kod fungerar för några handplockade scenarier. Egenskapsbaserad testning validerar att din kod fungerar för hela klasser av indata.

Vad är egenskapbaserad testning? Ett paradigmskifte

Egenskapsbaserad testning vänder på manuset. Istället för att påstå att en specifik indata ger en specifik utdata, definierar du en generell egenskap för din kod som ska gälla för alla giltiga indata. Testramverket genererar sedan hundratals eller tusentals slumpmässiga indata för att försöka bevisa att din egenskap är fel.

En "egenskap" är en invariant – en regel på hög nivå om din funktions beteende. För vår `sortNumbers`-funktion kan några egenskaper vara:

• Idempotens: Att sortera en redan sorterad array ska inte ändra den. `sortNumbers(sortNumbers(arr))` ska vara samma som `sortNumbers(arr)`.
• Längdinvarians: Den sorterade arrayen ska ha samma längd som den ursprungliga arrayen.
• Innehållsinvarians: Den sorterade arrayen ska innehålla exakt samma element som den ursprungliga arrayen, bara i en annan ordning.
• Ordning: För alla två intilliggande element i den sorterade arrayen, `sorted[i] <= sorted[i+1]`.

Detta tillvägagångssätt flyttar dig från att tänka på enskilda exempel till att tänka på det grundläggande kontraktet för din kod. Detta skifte i tankesätt är otroligt värdefullt för att designa bättre, mer förutsägbara API:er.

Kärnkomponenterna i PBT

Ett egenskapbaserat testramverk har typiskt två nyckelkomponenter:

1. Generatorer (eller Arbitraries): Dessa ansvarar för att producera ett brett utbud av slumpmässiga data enligt specificerade typer (heltal, strängar, arrayer av objekt, etc.). De är smarta nog att generera inte bara "happy path"-data utan också knepiga gränsfall som tomma strängar, `NaN`, `Infinity` och mer.
2. Krympning: Detta är den magiska ingrediensen. När ramverket hittar en indata som falsifierar din egenskap (dvs. orsakar ett testfel), rapporterar det inte bara den stora, slumpmässiga indatan. Istället försöker det systematiskt hitta den minsta och enklaste indata som fortfarande orsakar felet. Detta gör felsökning exponentiellt enklare.

Komma igång: Implementera PBT med `fast-check`

Även om det finns flera PBT-bibliotek i JavaScript-ekosystemet är `fast-check` ett moget, kraftfullt och väl underhållet val. Det integreras sömlöst med populära testramverk som Jest, Vitest, Mocha och Jasmine.

Installation och installation

Först lägger du till `fast-check` i ditt projekts utvecklingsberoenden. Vi antar att du använder en testkörning som Jest.

            npm install --save-dev fast-check jest
# eller
yarn add --dev fast-check jest
# eller
pnpm add -D fast-check jest
            

              
                Copy
              
            
          

Ditt första egenskapbaserade test

Låt oss skriva om vårt `sortNumbers`-test med `fast-check`. Vi kommer att testa "ordning"-egenskapen vi definierade tidigare: varje element ska vara mindre än eller lika med det som följer efter det.

            import * as fc from 'fast-check';

// Samma funktion som tidigare
function sortNumbers(arr) {
  return [...arr].sort((a, b) => a - b);
}

test('utdata från sortNumbers bör vara en sorterad array', () => {
  // 1. Beskriv egenskapen
  fc.assert(
    // 2. Definiera arbiträrerna (indatageneratorer)
    fc.property(fc.array(fc.integer()), (data) => {
      // `data` är en slumpmässigt genererad array med heltal
      const sorted = sortNumbers(data);

      // 3. Definiera predikatet (egenskapen som ska kontrolleras)
      for (let i = 0; i < sorted.length - 1; ++i) {
        if (sorted[i] > sorted[i + 1]) {
          return false; // Egenskapen är falsifierad
        }
      }
      return true; // Egenskapen gäller för denna indata
    })
  );
});

test('sortering bör inte ändra arraylängden', () => {
  fc.assert(
    fc.property(fc.array(fc.float()), (data) => {
      const sorted = sortNumbers(data);
      return sorted.length === data.length;
    })
  );
});
            

              
                Copy
              
            
          

Låt oss bryta ner detta:

• `fc.assert()`: Detta är löparen. Den kommer att köra din egenskapskontroll många gånger (100 som standard).
• `fc.property()`: Detta definierar själva egenskapen. Den tar en eller flera arbitrarier som argument, följt av en predikatfunktion.
• `fc.array(fc.integer())`: Detta är vår arbiträr. Den instruerar `fast-check` att generera en array (`fc.array`) med heltal (`fc.integer()`). `fast-check` kommer automatiskt att generera arrayer av olika längder, med olika heltalsvärden (positiva, negativa, noll, etc.).
• Predikatet: Den anonyma funktionen `(data) => { ... }` är där vår logik lever. Den får de slumpmässigt genererade data och måste returnera `true` om egenskapen gäller eller `false` om den kränks. `fast-check` stöder också predikatfunktioner som kastar ett fel vid fel, vilket integreras snyggt med Jests `expect`-påståenden.

Nu, istället för ett test med en handplockad array, har vi ett test som verifierar vår sorteringslogik mot 100 olika, automatiskt genererade arrayer varje gång vi kör vår svit. Vi har massivt ökat vår testtäckning med bara några rader kod.

Utforska arbiträrer: Generera rätt data

Kraften i PBT ligger i dess förmåga att generera mångfaldig och utmanande data. `fast-check` tillhandahåller en rik uppsättning arbiträrer för att täcka nästan alla datastrukturer du kan tänka dig.

Grundläggande arbiträrer

Dessa är byggstenarna för din datagenerering.

• `fc.integer()`, `fc.float()`, `fc.bigInt()`: För tal. De kan begränsas, t.ex. `fc.integer({ min: 0, max: 100 })`.
• `fc.string()`, `fc.asciiString()`, `fc.unicodeString()`: För strängar av olika teckenuppsättningar.
• `fc.boolean()`: För `true` eller `false`.
• `fc.constant(value)`: Returnerar alltid samma värde. Användbart för att blanda med `fc.oneof`.
• `fc.constantFrom(val1, val2, ...)`: Returnerar ett av de angivna konstanta värdena.

Komplexa och sammansatta arbiträrer

Du kan kombinera grundläggande arbitrarier för att skapa komplexa datastrukturer.

• `fc.array(arbitrary, constraints)`: Genererar en array med element som skapats av den angivna arbiträren. Du kan begränsa `minLength` och `maxLength`.
• `fc.tuple(arb1, arb2, ...)`: Genererar en array med fast längd där varje element har en specifik, annorlunda typ.
• `fc.object(shape)`: Genererar objekt med en definierad struktur. Exempel: `fc.object({ id: fc.uuidV(4), name: fc.string() })`.
• `fc.oneof(arb1, arb2, ...)`: Genererar ett värde från någon av de angivna arbitrarierna. Detta är utmärkt för att testa funktioner som hanterar flera datatyper (t.ex. `string | number`).
• `fc.record({ key: arb, value: arb })`: Genererar objekt som ska användas som ordböcker eller kartor, där nycklar och värden genereras från arbitrarier.

Skapa anpassade arbiträrer med `.map` och `.chain`

Ibland behöver du data som inte passar en standardform. `fast-check` låter dig skapa dina egna arbiträrer genom att transformera befintliga.

Använda `.map()`

Metoden `.map()` transformerar utdata från en arbiträr till något annat. Låt oss till exempel skapa en arbiträr som genererar icke-tomma strängar.

            const nonEmptyStringArb = fc.string({ minLength: 1 });

// Eller, genom att transformera en array med tecken
const nonAStringArb = fc.array(fc.char().filter(c => c !== 'a'))
                        .map(chars => chars.join(''));
            

              
                Copy
              
            
          

Använda `.chain()`

Metoden `.chain()` är mer kraftfull. Den låter dig skapa en ny arbiträr baserat på det genererade värdet av en tidigare. Detta är viktigt för att skapa korrelerade data.

Tänk dig att du behöver generera en array och sedan ett giltigt index för samma array. Du kan inte göra detta med två separata arbitrarier, eftersom indexet kan vara utanför gränserna. `.chain()` löser detta perfekt.

            // Generera en array och ett giltigt index i den
const arrayAndValidIndexArb = fc.array(fc.anything()).chain(arr => {
  // Baserat på den genererade arrayen `arr`, skapa en ny arbiträr för indexet
  const indexArb = fc.integer({ min: 0, max: arr.length - 1 });
  // Returnera en tupel av arrayen och det genererade indexet
  return fc.tuple(fc.constant(arr), indexArb);
});

// Användning i ett test
test('slicing at a valid index should work', () => {
  fc.assert(
    fc.property(arrayAndValidIndexArb, ([arr, index]) => {
      // Både `arr` och `index` garanteras vara kompatibla
      const sliced = arr.slice(0, index);
      expect(sliced.length).toBe(index);
    })
  );
});
            

              
                Copy
              
            
          

Kraften i krympning: Felsökning gjord enkel

Den enskilt mest övertygande funktionen i egenskapbaserad testning är krympning. För att se det i aktion, låt oss skapa en avsiktligt buggig funktion.

            // Denna funktion misslyckas om indata-arrayen innehåller talet 42
function sumWithoutBug(arr) {
  if (arr.includes(42)) {
    throw new Error('Detta nummer är inte tillåtet!');
  }
  return arr.reduce((acc, val) => acc + val, 0);
}

test('sumWithoutBug ska summera tal', () => {
  fc.assert(
    fc.property(fc.array(fc.integer()), (data) => {
      sumWithoutBug(data);
    })
  );
});
            

              
                Copy
              
            
          

När du kör detta test kommer `fast-check` nästan säkert att hitta ett felande fall. Men det kommer inte att rapportera den första slumpmässiga arrayen den hittade, som kan vara något som `[-1024, 500, 42, 987, -2000]`. En felrapport som den där är inte särskilt hjälpsam. Du skulle behöva inspektera den manuellt för att hitta det problematiska `42`.

Istället kommer `fast-check`s shrinker att sparka in. Den kommer att se felet och börja förenkla indatan:

• Kan jag ta bort ett element? Prova `[500, 42, 987, -2000]`. Misslyckas fortfarande. Bra.
• Kan jag ta bort ett till? Prova `[42, 987, -2000]`. Misslyckas fortfarande.
• ...och så vidare, tills den inte kan ta bort några fler element utan att få testet att passera.
• Den kommer också att försöka göra talen mindre. Kan `42` vara `0`? Nej, testet passerar. Kan det vara `41`? Testet passerar. Det minskar det.

Den slutliga felrapporten kommer att se ut så här:

Error: Property failed after 15 tests
{ seed: 12345678, path: "14", endOnFailure: true }
Counterexample: [[42]]
Shrunk 5 time(s)
Got error: This number is not allowed!

Den talar om för dig exakt, minimalt med indata som orsakade felet: en array som bara innehåller talet `[42]`. Detta pekar omedelbart på källan till buggen, vilket sparar dig enorm tid och ansträngning i felsökning.

Praktiska PBT-strategier och exempel från verkligheten

PBT är inte bara för matematiska funktioner. Det är ett mångsidigt verktyg som kan tillämpas på många områden inom mjukvaruutveckling.

Egenskap: Inversfunktioner

Om du har en funktion som kodar data och en annan som avkodar den, är de inverser av varandra. En bra egenskap att testa är att avkodning av ett kodat värde alltid ska returnera det ursprungliga värdet.

            // `encode` och `decode` kan vara för base64, URI-komponenter eller anpassad serialisering
function encode(obj) { return JSON.stringify(obj); }
function decode(str) { return JSON.parse(str); }

test('decode(encode(x)) ska vara lika med x', () => {
  // `fc.jsonValue()` genererar alla giltiga JSON-värden: strängar, tal, objekt, arrayer
  fc.assert(
    fc.property(fc.jsonValue(), (originalValue) => {
      const encoded = encode(originalValue);
      const decoded = decode(encoded);
      expect(decoded).toEqual(originalValue);
    })
  );
});
            

              
                Copy
              
            
          

Egenskap: Idempotens

En operation är idempotent om att tillämpa den flera gånger har samma effekt som att tillämpa den en gång. `f(f(x)) === f(x)`. Detta är en avgörande egenskap för saker som datastädningsfunktioner eller `DELETE`-slutpunkter i ett REST API.

            // En funktion som tar bort inledande/efterföljande blanksteg och kollapsar flera mellanslag
function normalizeWhitespace(text) {
  return text.trim().replace(/\s+/g, ' ');
}

test('normalizeWhitespace ska vara idempotent', () => {
  fc.assert(
    fc.property(fc.string(), (originalString) => {
      const once = normalizeWhitespace(originalString);
      const twice = normalizeWhitespace(once);
      expect(twice).toBe(once);
    })
  );
});
            

              
                Copy
              
            
          

Egenskap: Tillståndskänslig (modellbaserad) testning

Detta är en mer avancerad men otroligt kraftfull teknik för att testa system med internt tillstånd, som en UI-komponent, en kundvagn eller en tillståndsmaskin. Idén är att skapa en enkel mjukvarumodell av ditt system och en serie kommandon som kan köras mot både din modell och den verkliga implementeringen. Egenskapen är att tillståndet i modellen och tillståndet i det verkliga systemet alltid ska matcha.

`fast-check` tillhandahåller `fc.commands` för detta ändamål. Låt oss modellera en enkel räknare:

            // Den verkliga implementeringen
class Counter {
  constructor() { this.count = 0; }
  increment() { this.count++; }
  decrement() { this.count--; }
  get() { return this.count; }
}

// Kommandona för fast-check
const incrementCmd = fc.command(
  // check: en funktion för att kontrollera om kommandot kan köras på modellen
  (model) => true, 
  // run: en funktion för att köra kommandot på både modellen och det verkliga systemet
  (model, real) => {
    model.count++;
    real.increment();
    expect(real.get()).toBe(model.count);
  }
);

const decrementCmd = fc.command(
  (model) => true,
  (model, real) => {
    model.count--;
    real.decrement();
    expect(real.get()).toBe(model.count);
  }
);

test('Counter ska bete sig enligt modellen', () => {
  fc.assert(
    fc.property(fc.commands([incrementCmd, decrementCmd]), (cmds) => {
      const model = { count: 0 };
      const real = new Counter();
      fc.modelRun(() => ({ model, real }), cmds);
    })
  );
});
            

              
                Copy
              
            
          

I detta test kommer `fast-check` att generera en slumpmässig sekvens av `increment`- och `decrement`-kommandon, köra dem mot både vår enkla objektmodell och den verkliga `Counter`-klassen och säkerställa att de aldrig avviker. Detta kan avslöja subtila buggar i komplex tillståndskänslig logik som skulle vara nästan omöjlig att hitta med exempelbaserad testning.

När du INTE ska använda egenskapbaserad testning

PBT är ett kraftfullt tillägg till din testverktygslåda, men det är inte en ersättning för alla andra former av testning. Det är ingen silverkula.

Exempelbaserad testning är ofta bättre när:

• Testa specifika, kända affärsregler. Om en skatteberäkning måste producera exakt `$10,53` för en specifik indata, är ett enkelt exempelbaserat test tydligare och mer direkt. Detta är ett regressionstest för ett känt krav.
• "Egenskapen" är bara "indata X producerar utdata Y". Om det inte finns någon regel på högre nivå, generaliserbar regel om funktionens beteende, kan det vara mer komplext än det är värt att tvinga fram ett egenskapbaserat test.
• Testar användargränssnitt för visuell korrekthet. Även om du kan testa tillståndslogiken i en UI-komponent med PBT, hanteras kontroll av en specifik visuell layout eller stil bäst av ögonblicksbildstestning eller verktyg för visuell regression.

Den mest effektiva strategin är ett hybridtillvägagångssätt. Använd egenskapbaserade tester för att stresstesta dina algoritmer, datatransformationer och tillståndskänslig logik mot ett universum av möjligheter. Använd traditionella exempelbaserade tester för att spika specifika, kritiska affärsbehov och förhindra regressioner på kända buggar.

Slutsats: Tänk i egenskaper, inte bara exempel

Egenskapsbaserad testning uppmuntrar ett djupgående skifte i hur vi tänker på korrekthet. Det tvingar oss att ta ett steg tillbaka från enskilda exempel och beakta de grundläggande principer och kontrakt som vår kod bör upprätthålla. Genom att göra det kan vi:

• Uptäcka överraskande gränsfall som vi aldrig hade tänkt på att skriva tester för.
• Få mycket högre förtroende för robustheten i vår kod.
• Skriva mer uttrycksfulla tester som dokumenterar beteendet i vårt system snarare än bara dess utdata på några få indata.
• Minskar felsökningstiden drastiskt tack vare kraften i krympning.

Att anta egenskapbaserad testning kan kännas obekant till en början, men investeringen är väl värd det. Börja smått. Välj en ren funktion i din kodbas – en som hanterar datatransformation eller en komplex beräkning – och försök att definiera en egenskap för den. Lägg till ett egenskapbaserat test till ditt nästa projekt. När du bevittnar det hitta sin första icke-triviala bugg, kommer du att vara övertygad om dess kraft att bygga bättre, mer tillförlitlig mjukvara för en global publik.

Ytterligare resurser

• fast-check Official Documentation
• Förstå egenskapbaserad testning av Scott Wlaschin (en klassisk, språkoppert oberoende introduktion)